A non-volatile memory, such as a Flash memory or an EEPROM memory, is used in an electronic device to store non-volatile data. Such non-volatile data is also indicated as persistent data because its content may be variable during the programming phases of the electronic memory device, but its value must be preserved during the power off.
More particularly, the non-volatile memory ensures that the value of persistent data is not lost after a regular switch-off of the electronic device, i.e., when the electrical deactivation occurs in an idle state of the device. This is the typical case when the deactivation is driven by an operating system of a terminal that the device is connected to, or directly belongs to the electronic device.
If an accidental electrical deactivation occurs during an application execution, specifically during an updating operation of persistent data, it is possible that the value of persistent data is left in an inconsistent state. This could compromise, completely or partially, the functioning of the electronic device in the successive power-on sessions.
A prior art document, European patent no. 964,360, relates to a method for supplying power to integrated circuit cards comprising a microprocessor, a volatile memory (RAM) and a non-volatile memory (ROM, EEPROM) in case of an unexpected power off. This approach tries to overcome the above problem by always keeping the power supply to the memory device.
A second prior art document, U.S. published patent application no. 2005/0055498, relates to integrated circuit cards comprising failure protection for maintaining power in case of a power supply failure, and a power failure detector for sensing a corresponding power supply failure.
Those prior art documents disclose methods based on giving additional power to the electronic device for concluding sensitive operations before an unexpected switch off of the device. They do not consider a transaction method for storing persistent data in case of other unexpected events not determined by a power off.
A transaction method may restore the value of persistent data in a consistent state by generally grouping together an arbitrary number of writing operations, and establishing that they have to be considered as a single writing operation with respect to unexpected events comprising a power off. The arbitrary number of writing operations may be considered a “Secure Update” because the value of the persistent data they process are to be restored in a consistent state even if unexpected events occur.
More particularly, the transaction method marks all the writing operations involved in a “Secure Update” between first and second pseudo-instructions, respectively BeginTransaction and CommitTransaction, as schematically shown in FIG. 1.
In case of unexpected events during the execution of an operation included between the Begin Transaction and Commit Transaction, the values of the persistent data are restored in the non-volatile memory at the next device start-up to the value they had before the Begin Transaction instruction.
More particularly, the transaction method is based on a transaction stack, that is, a portion of non-volatile memory where the original value of persistent data involved in an update operation is stored before the starting of such an update. If an unexpected event occurs, the initial-consistent value of persistent data is retrieved from the transaction stack and restored in the non-volatile memory.
The non-volatile memory allows a limited number of writing accesses. Over this limit, the “data retention time” of the non-volatile memory decreases to values not acceptable for any application purpose. For example, the number of the allowed writing operations for EEPROM or Flash memories is typically in the range of 100,000 to 1,000,000.
This limitation has an impact on the implementation of the transaction method for driving the transaction stack, as any “Secure Update” involving a number of secure writing operations has the side effect of a further writing in the transaction stack. Moreover, depending on how the transaction method drives the storing of persistent data inside the transaction stack, different write operations may stress some bytes of the transaction stack more than others. In other words, different portions or bytes of the transaction stack could not be used uniformly.
The maximum number of writing operations on such particularly stressed bytes bounds the number of the “Secure updating” operations allowed to the applications on the non-volatile memory. Even if the device is guaranteed for 100,000 writing operations on each single byte of the non-volatile memory, the electronic device cannot perform more than 100,000 “Secure updating” even on different memory bytes. This is because in an opposite case, the bytes already stressed in the transaction stack could be damaged.
Moreover, current non-volatile memory devices, such as Flash memory devices and several EEPROM memory devices are based on a plurality of memory regions. Each memory region comprises a number of bits defining its granularity.
More particularly, it is nearly impossible to erase single bits within a memory region. The erasing of single or several bits within a memory region requires an erase of the whole region they belong to for granularity issues of the memory region. The same problem affects the updating operation because in such memories a writing operation first requires an erase operation to set the memory region in a “ready to be written” state.
When an unexpected event such as an accidental electrical power off occurs, because of the granularity issue, not only the bits involved in the actual write operation but all the bytes that belong to the memory regions involved in the update operation are affected by this problem. More particularly, this problem needs to be faced not only during a “Secure Update” but also during a non-secure update, hereinafter indicated as a “Non atomic update.” In other words, it is not required that all the operations involved in such an update are considered as a single atomic operation.
With reference to FIG. 2a, a non-volatile memory 1 is schematically shown as comprising a plurality of memory portions R1, R2, R3, R4. During a “Secure Update” instruction, memory portions R1, R2, R3 and R4 are involved in a writing operation. Such writing operations affect, for example, persistent data stored in memory sub-regions R1b of the portion R1, memory regions R2 and R3, and memory sub-regions R4a of the portion R4.
The location containing persistent data to be updated is pointed by a “Start address” pointer and has a size equal to “Length”. The transaction method needs to preserve the entire memory portions R1, R2, R3, R4 by storing all its content in a transaction stack, even if the writing operation does not affect the whole regions R1 and R4 but only the sub-regions R1b, R4a. Memory portions R1 and R4 need to be preserved completely because the writing operation requires an erase operation on them due to granularity issues.
FIG. 2b schematically shows the same non-volatile memory 1 wherein a “Non atomic Update” is performed. Also in this case memory portions R1, R2, R3, and R4 are involved in a non-atomic writing operation that affects persistent data stored in a location represented by memory sub-region R1b, memory regions R2 and R3, and memory sub-region R4a. 
Also in this case the transaction method preserves memory portions R1 and R4 because sub-regions R1a and R4b not directly involved in the writing operation need to be preserved. In contrast, regions R2 and R3 are not preserved. In fact, while the value involved in the “Non atomic update” and stored in the non-volatile memory could be deliberately left in a partially modified state due to not belonging to a “Secure Update,” it is not acceptable that the same happens for adjacent bits that do not have to be updated but are involved with the memory portions to be erased only because of granularity issues.
So, both “Secure Update” and “Non atomic update” operations would require a transaction method for preserving persistent data against possible unexpected events that occurred during update operations when determining an intensive use of the transaction stack.
The problem is that the lifetime of the non-volatile memory is limited due to writing operations on a transaction stack performed both during a “Secure Update” and also during a “Non atomic update” that stresses the transaction stack. This is especially so because the transaction stack needs to preserve a plurality of memory portions for the potential restoration of persistent data. This is not only during atomic updates but also during non-atomic updates that involve, for granularity issues, the erasing of persistent data that cannot be left in a non-consistent state.